Method and system for maintaining secure data input and output

ABSTRACT

Methods and systems for enhancing the security of data during input and output on a client computer system are provided to prevent attempts by unauthorized code to access, intercept, and/or modify data. Example embodiments provide a plurality of obfuscation techniques and security enhanced drivers that use these obfuscation techniques to prohibit unauthorized viewing/receiving of valid data. When the drivers are used together with the various obfuscation techniques, the security enhanced drivers provide mechanisms for “scheduling” the content of the storage areas used to store the data so that valid data is not available to unauthorized recipients. When unauthorized recipients attempt to access the “data,” they perceive or receive obfuscated data. The obfuscation techniques described include “copy-in,” “replace and restore,” and “in-place replacement” de-obfuscation/re-obfuscation techniques. In one embodiment, a security enhanced display driver, a security enhanced mouse driver, a security enhanced keyboard driver, and a security enhanced audio driver are provided. To complement the security enhancements, the methods and systems also provide for a watchdog mechanism to ensure that the driver is functioning as it should be and various user interface techniques for denoting security on a display device.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to methods and systems for maintaining thesecurity of data in a computer-based environment and in particular, tomethods and systems for maintaining the security of data as it is inputfrom an input device such as a mouse or keyboard and as it is outputthrough, for example, audio or video means.

2. Background Information

The concept of security continues to become increasingly more importantin a world where personal computer systems are generally connected viawireless or wired networks and/or internetworks, such as the Internet,to other computing systems. Many companies and institutions haveaddressed security issues as they relate to, for example, the transferof data from a personal (client) computer system to server computersystems over network communications. For example, firewalls aretypically present on local area networks (LANs) to form boundariesbetween the rest of the internetworking world and the computer systemson the LAN. In addition, widely used cryptography techniques are oftenapplied to such data transfers to ensure the security of the datacommunication paths.

However, there still remains a problem on the client computer systemsthemselves regarding valuable data that is often stored in valid form onthe client computer system even though it may be transmitted inencrypted form over a communications channel to a server machine. Forexample, a user desiring to buy an object over the Internet, may connectand log into a website and provide his/her credit card information inorder to purchase the object. Although the website (and client browseron the client machine) may support the transfer of the credit cardinformation using a secure communications layer (such as SSL—securesocket layer protocol), the credit card information, in order to bedisplayed on the display device of the client computer system actuallyresides in storage as valid data for some period of time. Unauthorized“hackers” can then access such stored data (providing they are not keptout by a firewall or have been installed as rogue applications on theclient computer system) using sophisticated mechanisms, even if the datais stored briefly. Thus, there is an ever-increasing need for providingtechniques for securing data on a client machine.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the present invention provide computer-based methods andsystems for enhancing the security of data during input and output on aclient computer system in order to prohibit and/or frustrate attempts byillegitimate processes, applications, or machines to obtain data in anunauthorized fashion. For the purposes of this description, “data”includes digital bits or analog signals in a computer system transferredor stored for any purpose, including graphics, text, audio, video, inputsignals, output signals, etc. Example embodiments provide a plurality ofobfuscation techniques and security enhanced, system level drivers thatuse these obfuscation techniques to prohibit unauthorizedreceivers/viewers of the data from receiving/viewing valid data. Whenthese obfuscation techniques are used with the security enhanceddrivers, the drivers can ensure that invalid data is alwaysreceived/viewed by unauthorized recipients/viewers, thus preventingunauthorized hackers with access to valid data. Several obfuscationtechniques by themselves offer varying levels of security.

For the purposes of this description, the term “obfuscation” refers toany mechanism or technique for transforming or hiding valid data so thatthe valid data becomes difficult to view, intercept, process, or modifywithout proper authorization and thus, appears as invalid data whenaccessed in an unauthorized manner. Obfuscation techniques may beimplemented as software, hardware, or firmware, depending upon theexecution environment of interest.

In some embodiments, the obfuscated data comprises, for example, anopaque color such as all black or all white, a pattern, a random bitmap,noise, masked data, an image, a company logo, or an advertisement. Othertypes of obfuscation, depending upon the type of data, are alsopossible.

For secure display of data on a display device and other types ofdisplay storage, the obfuscation techniques include “copy-out”, “replaceand restore,” and “in-place replacement.” These techniques specify where(and how) obfuscated data is de-obfuscated to generate valid data fordisplay and where (and how) data is re-obfuscated. Some techniquesutilize an overlay buffer or a mask buffer in conjunction with a framebuffer to accomplish the obfuscation process. Others take advantage ofany standard raster operation or overlay operation logic already presenton a video card. In other embodiments, the obfuscation techniques areapplied to the scheduling of content in other types of storage.

In some embodiments, the security enhanced drivers (SEDs) implementvarying degrees and levels of security, from making the data presentwith garbled information or noise, to encrypted data. The SEDs can beused with the different obfuscation techniques to determine what is usedto obfuscate data, how, and where the data comes from. The SEDs areresponsible for scheduling the obfuscation and de-obfuscation (andre-obfuscation) of the data.

In one embodiment, a security enhanced display driver (SEDD) is providedto schedule content of portions of a frame buffer stored in a videodisplay memory. In one such embodiment, a request to display data to asecure region on a video display made to the SEDD. In response, the SEDDallocates a corresponding secure portion of the frame buffer andschedules the data content of this secure portion such that valid datais only present in the secure portion at the time it is needed forprojection to the display device and when other tasks are locked out ofaccessing (reading or writing) to the secure portion. The SEDDdetermines, depending upon, the obfuscation techniques used, when datastored in the secure portion needs to be de-obfuscated and when it needsto be re-obfuscated.

In other embodiments, security enhanced drivers are provided for inputdevices, such as a mouse, keyboard, or other pointing device. These SEDsoperate by intercepting the input data as it comes directly from theinput device, transforming the data to an obfuscated form when secureinput data has been requested, and forwarding the transformed data tothe requesting code. When input data is received for a task that has notbeen authorized to receive secure data, then the input data is forwardedto standard operating system input drivers through a standard inputstack.

In some of these embodiments, the SEDs are installed first-in-line inthe driver processing sequence to ensure that the SED will intercept thedata prior to any other code. In some embodiments, monitoring and/orwatchdog services are spawned to ensure the security of thesefirst-in-line hooks.

In yet other embodiments, different techniques are provided to denotevarious levels of security offered in the system. Some of thesetechniques present information regarding the source of the security aswell. Techniques are present for manipulating standard user interfaceelements like scroll bars, titles, etc. as well as techniques thatmodify a cursor representation automatically as input focus travels fromone area into a different security area.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an example block diagram of the abstraction layers of astandard computing architecture that includes the security enhanceddrivers as provided by embodiments of the present invention.

FIG. 2 is an example block diagram of how data is transferred to adisplay device in a typical computer system.

FIG. 3 is an example block diagram that shows how display hackingoccurs.

FIG. 4 is an example block diagram of the general techniques used by anexample Security Enhanced Display Driver to prevent unauthorized accessto data stored in a frame buffer.

FIG. 5 is an example block diagram of a designated secure portion of thevideo display memory (VRAM) as provided by an example Security EnhancedDisplay Driver.

FIG. 6 is an example block diagram of obfuscation techniques used inconjunction with “copy out” de-obfuscation techniques.

FIG. 7 is an example block diagram of variations on copy outde-obfuscation techniques.

FIG. 8 is an example block diagram of obfuscation techniques used inconjunction with “replace and restore” de-obfuscation techniques.

FIG. 9 is an example block diagram of obfuscation techniques used inconjunction with “in-place replacement” de-obfuscation techniques.

FIG. 10 is an example illustration of the scheduling of obfuscation andde-obfuscation of the contents of the frame buffer by an exampleSecurity Enhanced Display Driver.

FIG. 11 is an example block diagram of an alternateobfuscation/de-obfuscation approach that can be used to schedule thetiming of obfuscation and de-obfuscation of the entire frame buffer.

FIG. 12 is an example flow diagram of an example application levelroutine for requesting rendering in a secure display region.

FIG. 13 is an example flow diagram of interfaces in an example SecurityEnhanced Display Driver to control obfuscation of a secure displayregion in a true multi-tasking, hardware event-driven system.

FIG. 14 is an example flow diagram of interfaces in an example SecurityEnhanced Display Driver to control obfuscation of a secure displayregion in a non-event driven manner in an alternate operating systemenvironment.

FIG. 15 is an example flow diagram of a vertical blank timing andsynchronization thread used to control the frame buffer contentscheduling in the alternate operating system environment of FIG. 14.

FIG. 16 is an example flow diagram of code for determining correlationsbetween vertical blank and VRAM address as used to control frame buffercontent scheduling.

FIG. 17 is an example flow diagram of a real-time obfuscation controlthread used by the Security Enhanced Display Driver to deliver valid andinvalid data to the frame buffer.

FIG. 18 is an example block diagram that illustrates how input datahacking occurs.

FIG. 19 is an example block diagram of the general techniques used by asecurity enhanced input driver, such as a Security Enhanced Mouse Driverto prevent unauthorized access to input data.

FIG. 20 is an example flow diagram of the obfuscation techniques used byan example Security Enhanced Keyboard Driver to prevent unauthorizedaccess to input data.

FIG. 21 is an example block diagram that illustrates how audio datahacking occurs.

FIG. 22 is an example flow diagram of the obfuscation techniques used byan example Security Enhanced Audio Driver to prevent unauthorized accessto audio data.

FIG. 23 is an example block diagram of installing a security enhanceddriver as a first-in-line driver in Windows 9x operating systemenvironments and associated monitoring processes.

FIG. 24 is an example screen display that illustrates a padlock todenote security as used in an existing software application.

FIG. 25 is an example screen display that illustrates use of the cursorto determine a security level and other representations on windows usedto denote security.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the present invention provide computer-based methods andsystems for enhancing the security of data during input and output on aclient computer system in order to prohibit and/or frustrate attempts byillegitimate processes, applications, or machines to obtain data in anunauthorized fashion. For the purposes of this description, “data”includes digital bits or analog signals in a computer system transferredor stored for any purpose, including graphics, text, audio, video, inputsignals, output signals, etc. Example embodiments provide a plurality ofobfuscation techniques and security enhanced (typically, system level)drivers that use these obfuscation techniques to prohibit unauthorizedreceivers/viewers of the data from receiving/viewing valid data. Whenthese obfuscation techniques are used with the security enhanceddrivers, the drivers can ensure that invalid data is alwaysreceived/viewed by unauthorized recipients/viewers, thus preventingunauthorized hackers with access to valid data. Several obfuscationtechniques by themselves offer varying levels of security.

For the purposes of this description, the term “obfuscation” refers toany mechanism or technique for transforming or hiding valid data, sothat the valid data becomes difficult to view, intercept, process, ormodify without proper authorization, and thus appears as invalid datawhen accessed in an unauthorized manner. (The word “obfuscate” means torender obscure.) Obfuscation techniques may be implemented as software,hardware, or firmware, depending upon the execution environment ofinterest. Although standard encryption techniques are one type ofobfuscation, a variety of others can be employed includingtransformations of data between valid forms and invalid forms, temporaryand dynamic movement of noise data throughout otherwise valid data, etc.The methods and systems of the present invention describe manytechniques for thus preventing unauthorized hacking and retrieval ofdata. Hacking, for the purposes used herein, describes any type ofillegal and/or unauthorized use or view of data, using any technique forintercepting data or for monitoring data or access patterns.

The security enhanced drivers (SEDs) implement varying degrees andlevels of security, from simply storing or presenting the data withgarbled information or noise, encrypted data, to data that is perceivedor received as invalid by unauthorized code. In each case, a centralfocus of each security enhanced driver is to store and present validdata as obfuscated (and thus invalid) data to unauthorized “clients”(code, users, hardware, etc.). In one embodiment of the presentinvention, the security enhanced drivers include a security enhanced(video) display driver (SEDD); a security enhanced mouse driver (SEMD),which techniques are useful generally to any pointing type input device(or any x,y coordinate input device); a security enhanced keyboarddriver (SEKD); and a security enhanced audio driver (SEAD). Each ofthese drivers and the concomitant obfuscation techniques that can beapplied are discussed in the subsections that follow. One skilled in theart will recognize that other drivers for other types of input andoutput devices may be similarly designed and/or implemented using thetechniques, methods, and systems described herein.

FIG. 1 is an example block diagram of the abstraction layers of astandard computing architecture that includes the security enhanceddrivers as provided by embodiments of the present invention. In FIG. 1,as is typical in many computer systems, the operating system layer 101,including the kernel and operating system device drivers (such as themouse, keyboard, display, audio, and network drivers) resides at thebottom of the software execution architecture. The operating systemlayer 101 communicates directly with the hardware and/or hardwareinterface cards, such as mouse 110, keyboard 120, display 130, andnetwork interface card 140. One skilled in the art will recognize thatother hardware and other drivers even though not shown (including audioplayers and associated operating system audio drivers) also may residein such a system. Above the operating system device drivers, other(typically, higher level) driver software 102 executes and provides morecomplex abstractions of the hardware to the applications layer 104 andapplication software libraries 203. Driver software 102 includesinterfaces and libraries of functions that help applications receive andprocess input and output such as a mouse and keyboard interfaceproviding by a windowing interface, or a display interface such asWindows operating system GDI. Applications APIs 103, often provide evenhigher level abstractions to applications 104, such as reusable objectsthat can be subclassed in object-oriented application code. At the toplevel, the (desktop) applications 104 typical execute on top of all ofthe other layers and communicate progressively through each layer toprocess input and output from and to the hardware. In some embodimentsof the present invention, the security enhanced drivers (SEDs) 406preferably reside between the operating system device drivers 405 andthe hardware so as to better control secure processing of input andoutput in the lowest layers of a computing system.

In order to implement data obfuscation in a manner that ensures validdata only to authorized clients, each SED typically needs to have sometype of mechanism for locking out a part of the system (a resource suchas a portion of a frame buffer on a video card). Because varyingoperating systems (kernels, or other process schedulers) providedifferent mechanisms for ensuring that a driver will have “priority” inthe scheduling of operating system tasks (processes, threads, code ofany type, etc.), it is often necessary to implement a mechanism forensuring that a SED is a “first level driver” in the system. That is, amechanism needs to be present to ensure that the driver that is“hooking” the input or output can obtain the data first, before otherdrivers or code, such as operating system drivers (OS device drivers 105in FIG. 1). One technique is to implement the SED as a system leveldriver, initialize the system to include this driver as the first driver“in line” (of its type, or in the overall event processing driver chain,where applicable), and to provide a “watchdog” process for monitoringthe position and security of the SED. Different operating systemsrequire different techniques for installing a driver as first-in-line,and what first-in-line means. Techniques for installing a driver asfirst-in-line will be apparent to those skilled in the art, dependingupon the operating system. A description of example implementationsusing Windows 9X and Windows NT derivatives is described in the sectionentitled “First-in-line SED Installation and Watchdog Monitoring.”

To complement the obfuscation techniques and security enhanced drivers,the methods and systems of the present invention also provide differenttechniques for denoting various levels of security in the system.Example screen displays of these techniques are provided and describedrelative to FIGS. 24-25. One skilled in the art will recognize thatother techniques for denoting security are possible and equivalent infunction.

Secure Storage and Display of Video Content

Video content is generally vulnerable to hacking on a variety of levelsand in different scenarios. FIG. 2 is an example block diagram of howdata is transferred to a display device in a typical computer system. InFIG. 2, the operating system and applications 201 communicate with anoperating system display interface 202 (typically, a graphics librarysuch as GDI in the Window operating system environment) to draw to a“desktop canvas”—a bitmap representation of the area of the displaydevice 220 that the operating system controls for its user interface.(This bitmap is typically stored in random access system memory (RAM)and may be hidden to applications through mechanisms of the OS.) Thedisplay driver of the operating system (OS) than sends this bitmap tothe video card for storage in the video display memory 203 (e.g., VRAM)residing on the card. The bitmap to be drawn is typically stored in adesignated portion of the VRAM, called the frame buffer 204, as a staticbitmap. The area of the frame buffer 204 that corresponds to the portionof the display device 220 (screen) used by the OS user interface(typically referred to as the “Desktop”) may be a portion of the entireframe buffer 204. That is, the operating system 204 (and applications)may not use the entire displayable area of the display 220. The portionof the display 220 used by the operating system 204 is typicallydescribed and set by well-known video modes, represented in resolutioncoordinates, such as a 1024×768 (pixel) area. (Applications andtechniques for extending the use of a display device (through what issometimes referred to as “physical overscan”), or for sharing thedisplay device between the OS user interface and an area of the displaynot accessible to the OS, are described in detail in co-owned U.S.patent application Ser. No. 09/726,202, entitled “Method and System forControlling a Complementary User Interface on a Display Surface,” filedNov. 28, 2000, U.S. Pat. No. 6,018,332, entitled “Overscan UserInterface,” issued on Jan. 25, 2000, and U.S. Pat. No. 6,330,010,entitled “Secondary User Interface”, issued on Dec. 11, 2001, and otherrelated patents.) The VRAM 203 is also used by the video card (and videodrivers) to store other types of information. In a typical PCenvironment, now with advanced video cards, one or more “overlay”buffers 205 may reside also in the VRAM 203. In these cards, advancedlogic is provided to enable a graphics processing unit (GPU) (or otherelement responsible for transferring data from VRAM 203 to the displayscreen 220) to “overlay” bits from the overlay buffer 205 as the GPU iscopying out bits from the frame buffer 204 to the display 220. In somecards, the overlay bits are combined with corresponding bits from theframe buffer 204 using complex logic, ranging from “AND” and “XOR”operations to other types of percentage operations. (For example, theGPU may combine 70% of bit x,y from the frame buffer 204 “OR”ed with 30%of bit w,z from the overlay buffer 205, sometimes referred to as alphablending.) Such cards often provide these bitmap operators to combine anarea of VRAM 203 with another area of VRAM 203 (or designated memoryelsewhere) to code other than the GPU, and will be referred to as RasterOperations.

While the data is stored in an area of the VRAM 203 that is accessibleto system level code (such as software and hardware video drivers, andother code that known how to communicate directly with the video card,e.g., Direct-X and DirectDraw), which is typically when the data isappearing on the display device 220, the data is vulnerable to hackingby malicious programs. FIG. 3 is an example block diagram that shows howdisplay hacking occurs. In FIG. 3, the operating system memory (RAM)301, as was described in FIG. 2, holds the bitmap that represents thedesktop canvas. At this point, Trojan Horse application 320 can access acopy of the desktop canvas (if it knows how to locate the desktop canvasin RAM) and can transfer that copy, across a network or by any otherdata communication path to other computers, such as hacker computers321. (The application 320 is referred to as a “Trojan horse” because ithas been injected, typically, in an unauthorized and undetected fashiononto the client computer system.) One technique for avoiding suchunauthorized access is for the operating system to store the bitmap inan obfuscated form and de-obfuscate (or un-obfuscate) the bitmap when itis sent to the video card to be stored in VRAM 302. The termde-obfuscate (or un-obfuscate) is used to refer to the reverse processused to obfuscate data. Thus, for example, decryption of encrypted datais a de-obfuscation process, as is applying an XOR operation with a maskto data that has been obfuscated by applying an XOR operation to thatsame mask.

Once the data is stored in VRAM 302, the data is still vulnerable toillicit copying or viewing by an unauthorized client, for example, arogue application 322 that uses a library, such as Direct-X, tocommunicate directly with the video card. The data is ripe for hackingas long as the video card needs to store the valid data in VRAM to allowthe GPU to project the data onto display device 303. A Security EnhancedDisplay Driver is provided by the methods and systems of the presentinvention to prevent this type of hacking at lower levels in the system;that is, the enhanced driver supports techniques that secure designateddata that is temporarily stored in conjunction with the video card anddisplay mechanisms.

FIG. 4 is an example block diagram of the general techniques used by anexample Security Enhanced Display Driver to prevent unauthorized accessto data stored in a frame buffer. The diagram shows the same componentsas shown in FIG. 3, and the attempted hacking mechanism, but adds anadditional component, the Security Enhanced Display Driver (the SEDD).The SEDD operates by applying obfuscation techniques to data stored indesignated areas (and potentially the whole) of the frame buffer in VRAM402 so that, even if an unauthorized application, such as rogueapplication 422 attempts to copy-out data from the frame buffer 402, thedata is invalid data because it has been obfuscated by the SEDD. Sincethe SEDD obfuscates (one or more) portions of the frame buffer 402, inorder to effectively display the valid (un-obfuscated) data, the SEDD404 needs to temporarily de-obfuscate the data, so that the GPU copiesout valid data at the time the GPU requires the data to be valid forcorrect display on display device 403. Thus, in general, the SEDD 404acts as a “scheduler” process for the content of the frame buffer, inthat it controls when the frame buffer holds valid data and invaliddata, where the valid/invalid data is located in the frame buffer, andwhere the valid/invalid data is stored to be used to populate areas inthe frame buffer. The SEDD may incorporate a variety of mechanisms toobfuscate and de-obfuscate data, including those described below withreference to FIGS. 6-9.

In one embodiment, the SEDD supports the ability for an application (orother code) to define a region on the display device as a “secureregion.” Depending upon the level of security implemented in theparticular system, the SEDD is able to guarantee that level of securityfor the secure region. For example, if the highest level of security isoffered, the SEDD ensures that no unauthorized process can view orintercept the valid data, from the frame buffer, while it is beingdisplayed in the secure area. In that scenario, a user can see the dataon the display screen, but the secure region appears obfuscated to allcode (other than the scheduler and driver processes).

FIG. 5 is an example block diagram of a designated secure portion of thevideo display memory (VRAM) as provided by an example Security EnhancedDisplay Driver. The VRAM 506 is shown in correspondence to the portionof the frame buffer (in this case the whole frame buffer) displayed ondisplay device 501. The frame buffer 507 in this example is shown as a1024×768 pixel area on display device 501. On display device 501, thenative desktop display area 502 (operating system controlled userinterface) is shown in conjunction with two designated secure regions503 and 504. In the corresponding positions in the frame buffer 507 ofthe VRAM, the native desktop portion 510 is shown in conjunction withsecure portions of the frame buffer 511 and 512. To other code, secureportions 511 and 512 appear as obfuscated (as noted there bycrosshatching). Other storage locations are also resident in VRAM 506,such as secure driver areas 508 and an overlay buffer 509. Secure driverareas 508 store different buffers used by the SEDD and are not allocatedby standard OS and programming means (i.e., a “malloc” function), butrather are explicitly requested from the video card and thus access canbe better controlled by the SEDD. In particular, buffers for holdingvalid data (a Valid Data Buffer, or VDB), encrypted or masked valid data(a Secure Data Buffer, or SDB) and a mask buffer (Mask Buffer, or MB)are shown residing in Other VRAM 508.

Once one or more secure regions are defined, the content of the framebuffer (FB) is appropriately scheduled by the SEDD. In essence, the SEDDensures that the contents of the secure portion of the FB thatcorresponds to the secure region on the display contains valid data whenthe GPU needs to read it (or the GPU obtains the valid data throughother means), and at (effectively and practically speaking) all othertimes, the contents of the secure portion contains obfuscated data. Thevarious obfuscation and de-obfuscation approaches used in conjunctionwith the SEDD are described with reference to FIGS. 6-9. One skilled inthe art will recognize that other variations and nuances of theseapproaches and new approaches yet to be developed are operable with theSEDD and contemplated as part of the invention and that those discussedbelow are provided as examples. Also, one skilled in the art willrecognize that the separate “cases” shown are organized as such for easeof description and may or may not resemble any actual implementation ordivision of functionality.

The first obfuscation/de-obfuscation approach is termed “copy out,”because, in summary, valid data is provided by the SEDD to be projectedon the display device at “copy out” time—when the GPU copies the secureportion of the frame buffer to the corresponding secure region on thedisplay. FIG. 6 is an example block diagram of obfuscation techniquesused in conjunction with “copy out” de-obfuscation techniques. Accordingto the “copy out” approach, the data in the secure portion is invalid,thus the complex scheduling techniques that insert valid data in theframe buffer at critical times and restore invalid data at other timesare not necessarily used. (These complex scheduling techniques arediscussed below with reference to FIGS. 10-17.) In particular, validdata is passed to the display device; however, it may not be directlycopied out from the frame buffer (FB). Preferably, the residenttechnique used by the video card (the GPU) to combine the overlay bufferwith the frame buffer prior to projection is instead used to combine theobfuscated data in the frame buffer with the data in the overlay buffer.

There are two cases to consider. In the first case, Case 1, the framebuffer 601 contains invalid data in the secure portion 605 and validdata is stored in another buffer 602. Other data (shown as valid data)is stored in the areas of the frame buffer that are not designated assecure portions. The SEDD uses the valid data in buffer 602 to overwritethe contents of secure portion 605 when the FB data is copied out to thedisplay device 603. The buffer 602 could be the overlay buffer, insystems that support direct raster operation combinations of thecontents of the overlay buffer and the frame buffer. Further, theoverlay buffer may contain an encrypted version of the valid data (withnoise, for example, stored in the secure portion 605). In the lattercase, a decryption key is stored in some auxiliary location. One skilledin the art will recognize that, although referred to as the overlaybuffer (for video card and system supported mechanisms), other bufferssuch as a valid data buffer (VDB) or a secured data buffer (SDB), storedelsewhere in VRAM may be used in combination with raster operations. Inthe second case, Case 2, the invalid data stored in the secure portion606 is an encrypted or masked version of the valid data and anencryption key or a mask used to unmask the masked version of the validdata is stored in another buffer 604. The key or mask stored in thebuffer 604 is used to create valid data on copy out by either decryptingthe data stored in the secure portion 606, or by combining the datastored in the secure portion 606 using a Raster Operation (ROP) and themask stored in the buffer 604. The primary distinction between the firstand second cases is whether the data stored in the other buffer (602 or604) is valid data or other (key or mask) data. One skilled in the artwill recognize that some use the work “mask” interchangeably with theterm “key,” and for the purposes described herein, the terms areinterchangeable.

FIG. 7 is an example block diagram of variations on copy outde-obfuscation techniques. This technique is useful in combination withthe “copy-out” techniques of FIG. 6 to partially obfuscate a secureportion of the frame buffer. In particular, in FIG. 7, VRAM 700 is shownwith a secure portion (herein termed a “frame” ready to be displayed.Instead of, as in FIG. 6, obfuscating the entire secure portion, atechnique is used to subdivide the secure portion into, for example,three sub-portions, and to treat one of the sub-portions as theobfuscated area that is overwritten by valid data or is used to createvalid data (cases 1 and 2 in FIG. 6). In the example shown, valid data(the frame to be displayed) from the operating system being sent to thevideo card (through the SEDD) is subdivided in three subparts before itis stored in the VRAM. The first subpart 704 of valid data is loadedinto the first sub-portion 707 of the frame buffer; the middle subpart705 of valid data is stored in the overlay buffer 702; and the lastsubpart 706 is stored as valid data in the third sub-portion 709 of theframe buffer. Obfuscated data (of any desired content or format and fromany source) is stored in the middle subpart 708 of the frame buffer. Thebottom portion of FIG. 7 shows how a GPU would use a combination of theoverlay buffer and the portions of the frame buffer to generate validdata for projection on the display device.

The second obfuscation/de-obfuscation approach is termed “replace andrestore,” because, in summary, the SEDD provides valid data by replacingthe invalid data stored in the secure portion of the frame buffer withvalid data just prior to being projected (or during projection) on thedisplay device—when the GPU copies the secure portion of the FB to thecorresponding secure region on the display—and provides obfuscated databy restoring the invalid data after (or during the time) the secureportion of the FB is projected by the GPU. (The exact timing of thede-obfuscation and re-obfuscation is dependent upon whether data isbeing handled pixel-by-pixel, scan-line at a time, or in blockoperations.) FIG. 8 is an example block diagram of obfuscationtechniques used in conjunction with “replace and restore” de-obfuscationtechniques. In FIG. 8, the frame buffer 801 (initially) containsobfuscated data in the secure portion 802 of the FB. Other data (shownas valid data) is stored in the areas of the frame buffer that are notdesignated as secure portions. Again, there are two cases to consider,which differ as to whether valid data destined for the secure portion ofthe frame buffer is stored as valid data (e.g., in a valid data buffer,VDB) or is stored as encrypted or masked data (e.g., in a secure databuffer, SDB) which is decrypted or de-masked prior to copying in the“valid” data into the frame buffer.

In particular, in Case 3, valid data is stored in valid data buffer(VDB) 803 and obfuscated data (or data, for example, a mask, used toobfuscate the contents of the secure portion of the FB) is stored in amask buffer (MB) 804. Recall that these buffers may be stored whereverit is convenient in the system and meets the security needs intended.The SEDD, at an appropriate time prior to the time when the contents ofthe secure portion needs to be valid for projection, copies in validdata from VDB 803. After the valid data has been scanned and copied outfor projection to the display (or sometime in the interim), the SEDDcopies-in the invalid data from the mask buffer 804 in order tore-obfuscate the secure portion of the FB 802. Note that, although shownas coming from the mask buffer 804, one skilled in the art willrecognize that the invalid data may be created any number of ways,including system operations, machine instructions, or other means thatturn a set of bits on (all black) or clear the bits (all white). Asshown in the figure, when the obfuscated data is to be formed by maskingversions of the valid data, then a mask can be stored in MB 804 andapplied to the already copied-in valid data stored in the secure portion802 using ROPs to recreate the newly obfuscated data. Alternatively,when the obfuscated data is invalid data such as a logo, advertisement,or random bit patterns, then invalid data from the mask buffer 802 canbe copied in to the frame buffer as is.

In Case 4, valid data is only stored in a more secure form (such asstored as encrypted or masked data) in secure data buffer (SDB) 805.This same encrypted or masked data (since it is “obfuscated” data) isused as the invalid data to be copied in to the secure portion of the FBwhen obfuscated data is to replace the valid data in the frame buffer. Amask or key is stored in mask buffer (MB) 804 to be used by the SEDD todecrypt or de-mask the secure data stored in SDB 805. Thus, the SEDD, atan appropriate time prior to the time when the contents of the secureportion 802 needs to be valid for projection, creates valid data to copyin from the SDB 805 by applying (decrypting or de-masking) a key or maskfrom the MB 804 to the secure data stored in the SDB 805, and copies outthe result (valid data) to the secure portion of the FB 802. Similarly,after the valid data stored in the secure portion 802 has been scannedand copied out for projection (or thereabouts), the SEDD copies-in theinvalid data (the encrypted or masked form of the valid data) from SDB805 in order to re-obfuscate the secure portion of the FB 802.

The third obfuscation/de-obfuscation approach is termed “in-placereplacement,” because, in summary the SEDD provides valid data in thesecure portion of the frame buffer by manipulating the invalid datain-place just prior to being projected on the display device—when theGPU copies the secure portion of the FB to the corresponding secureregion on the display—and then provides invalid data by manipulating(toggling) the valid data in-place to once again generate invalid data.FIG. 9 is an example block diagram of obfuscation techniques used inconjunction with “in-place replacement” de-obfuscation techniques. InFIG. 9, the frame buffer 901 (initially) contains obfuscated data in thesecure portion 902 of the FB. The obfuscated data is a secure version ofthe valid data, such as an encrypted or masked form of the valid data.Hence, to create valid data from the obfuscated data (to de-obfuscatethe data) stored in the secure portion of the FB 902, the SEDD appliesan appropriate key or mask, stored in mask buffer (MB) 904, to decryptor to de-mask the data as appropriate. Like the approaches “replace andrestore” approach described with reference to FIG. 8, the SEDD performsthe de-obfuscation and re-obfuscation at the appropriate times to ensurethat projection of valid data is possible and that no other code hasaccess to the valid data that corresponds to the secure portion 802.

As described relative to FIGS. 8 and 9, the SEDD needs to schedule thede-obfuscation and re-obfuscation of data stored in a secure portion ofthe frame buffer in order to coordinate valid data for projection useand obfuscated data for security. FIG. 10 is an example illustration ofthe scheduling of obfuscation and de-obfuscation of the contents of theframe buffer by an example Security Enhanced Display Driver. The graphshown in FIG. 10 relates the time taken for a display gun to scan data(typically scan line at a time) from the frame buffer for projection onthe display device to the address locations in the frame buffer memory.A vertical blank signal is given by the gun when it reaches the end ofscanning the display, just prior to its return to scanning the firstline on the display screen. The time the gun takes to travel from thelower rightmost corner to beginning scanning again in the upper leftmostcorner is referred to as a vertical blank interval (this when the screenused to “blink” prior to advanced technical which makes this timevirtually undetectable). This time is calculable for a particular systemwhose gun paints at a particular rate (typically in hertz).

Note that the (0,0) point is simply an origin relative to the screen(the upper leftmost corner). The actual portion of the display screenbeing used by the operating system and other code, may in fact be lessthan the total amount on the screen. The relative origin point in theframe buffer used as a data source for what is scanned to the display isalso described as (0,0), however, it will be understood that this pointis not necessarily the first address location available in the framebuffer.)

The gun projects scan lines (travels) at a particular rate. The SEDDneeds to determine when the gun will reach point A. Point A representsthe time (relative to the VB signal end at origin 0,0) the gun willreach the beginning of a designated secure region on the display, whichcorresponds to a designated secure portion of the frame buffer (memory).At point A, the data in the secure portion of the FB needs to be validdata. Point B represents the relative time when the gun will reach theend of scanning the designated secure region on the display, whichcorresponds to the end of the secure portion of the frame buffer. Bypoint B, the data in the secure portion of the FB needs to be obfuscateddata, so that other code (code other than any SEDD code used in thescheduling of frame buffer content) cannot view or intercept valid data.In reality, due to system latencies, including the VB interval to startscanning from the display origin, the time to load code and invokeprocesses, threads etc., and due to any time needed for thede-obfuscation (including in some cases decryption) to occur, the SEDDneeds to start the process of de-obfuscated the data stored in thedesignated secure portion of the frame buffer at some time prior to whenit is needed at point A. Point C represents this time delta. One skilledin the art will recognize that the values of points A, B, and C arehighly system dependent. Points A and B can be determined by polling forthe VB signal or, in an event-driven system that supports VB events, byreceiving a VB event and calculating (knowing the travel rate of thegun) the time it will take to reach point A and point B. Point C,however, the time delta, is typically determined empirically, based uponsystem latencies and the particular obfuscation and de-obfuscationtechniques being used. In general, point C is:point A (in time)−system latency time−de-obfuscation process time   (1)

One skilled in the art will recognize that many different techniques canbe used from a scheduling perspective for re-obfuscating the data bypoint B. For example, the re-obfuscation process make take place a scanline at a time, pixel by pixel, or as a block of memory. Thus, theprocess may trail the gun by some interval. As described below relativeto FIG. 17, in one embodiment, re-obfuscation is performed right afterthe secure region is scanned for projection onto the display.

Also, in order to prevent other code from accessing the valid data whileit is present in the secure portion of the frame buffer, someprocess/thread locking mechanism needs to be employed to lock out othercode during critical intervals. In the embodiment described belowrelative to FIGS. 12-17, a real time, highest priority thread is used tocopy-in the valid data and to re-obfuscate the data prior torelinquishing control. One skilled in the art will recognize that othermechanisms can be used, and the level of security provided by the systemis commensurate with how lock proof the locking mechanism is.

FIG. 11 is an example block diagram of an alternateobfuscation/de-obfuscation approach that can be used to schedule thetiming of obfuscation and de-obfuscation of the entire frame buffer orsome portion thereof. Frame buffer 1100 can be thought of as a sequenceof areas, for example 1101-1104, that are in some state of containingobfuscated data and valid data. As the SEDD moves through the framebuffer 1100, it progresses through the areas in groups of three, sothat, at any one point in time there is an area 1103 that contains validdata being copied-out for display, an area 1102 Oust prior to 1103) thatcontains data in the process of being de-obfuscated, and an area 1104Oust after 1103) that contains data that is in the process of beingre-obfuscated. One skilled in the art will recognize that process/threadscheduling locks still should be asserted and relinquished asappropriate for the area in which valid data is present, for example1103, in order to achieve greater security. Alternatively, sincevariation of parameters such as the location and the size of the areasmay be changed, the state of the frame buffer may be sufficientlyunpredictable to outside code.

FIGS. 12-17 describe an example embodiment of how portions of a SEDDaccomplish the scheduling of content in the frame buffer to implementsecure regions on a display device. For the purposes of example, thescheduling scenario as described with reference to FIG. 10 is used.Also, in the following description, numerous specific details are setforth, such as data formats and code sequences, etc., in order toprovide a thorough understanding of the techniques. One skilled in theart will recognize, however, that embodiments of the present inventionalso can be practiced without some of the specific details describedherein, or with other specific details, such as changes with respect tothe ordering of the code flow, how the code flow is organized byfunction, etc. In addition, although certain parameters may be describedas input and output parameters, fewer or greater or different parametersmay be incorporated, depending upon the specific implementation.

In summary, at typically an application or operating system level, arequest will be made to create a secure region on the display device andto render data into that region in a secure fashion. This request willbe processed by the SEDD, which schedules the content of the framebuffer according to the scheduling plan (e.g., FIGS. 10 and 11) ineffect and the obfuscation and de-obfuscation techniques being used.

FIG. 12 is an example flow diagram of an example application levelroutine for requesting rendering in a secure display region. The API(referred to as “CreateSecureDisplayRegion”) takes as input a desiredlocation and returns an indication of a secure area on the video card(e.g., a valid data buffer) for storing the valid data, an indicator ofthe secure FB location allocated, and an identifier to be used toidentify this instance of a secure region. In step 1201, the APIauthenticates the requestor using, typically, standard techniques wellknown in the art, such as digital signatures, etc. In step 1202, the APIdetermines whether the secure region being request is available, and, ifso, continues in step 1204, else returns an error. In one embodiment,secure regions cannot overlap (interfere) with FB locations in anothersecure region, in order to guarantee the integrity and correctness ofthe data being displayed. One skilled in the art will recognize,however, that other implementation are possible. In step 1203, the APIallocates the secure region (by setting up the various return values forthe requester. The allocation step could also be done at the driver(SEDD) level instead. In step 1204, the API invokes the SEDD to startthe obfuscation process on the allocated region and returns. In oneembodiment, the driver is invoked through a standard device driver“ioctl” mechanism, which allows drivers to setup standard and specialentry points.

Once the driver is invoked, a number of steps happen, which aredependent upon the operating system being used, especially what events(signals) can be received and what task (process/thread, or . . . )locking mechanisms are available. FIGS. 13 and 14 are exampleembodiments of the ioctl entry point to start obfuscation based uponwhether the system supports vertical blank (VB) event registration ofwhether a polling (spin-lock) technique needs to be used, respectively.

FIG. 13 is an example flow diagram of interfaces in an example SecurityEnhanced Display Driver to control obfuscation of a secure displayregion in a true multi-tasking, hardware event-driven system. Insummary, the driver code determines where the projection gun needs to bein order to start obfuscation, registers for a VB event at that locationin the frame buffer, and spawns a real time thread to de-obfuscate andre-obfuscate the secure portion when the VB event is received.Specifically, in step 1301, the code determines whether the driver hasbeen invoked at the entry point corresponding to the “start obfuscation”process and, if so, continues in step 1302, else continues in step 1307.In step 1302, the driver code allocates a secure portion of the framebuffer to correspond to the secure region on the display, if this is notalready done by the corresponding API. In step 1303, the code determinesa VB_event_start location(time) in the frame buffer for starting thede-obfuscation process and a VB_event_end location(time) in the framebuffer for starting the re-obfuscation process13 that is, a VB eventspecification that corresponds to the beginning location of the secureportion in the frame buffer adjusted for latencies, de-obfuscation, etc.(see Equation 1 above) and determines a VB event specification thatcorresponds to the end. A process for determining the VB_event_start andVB_event_end is described below with reference to FIG. 16. In step 1304,the driver code registers for a VB event at time VB_event_start and thenwaits to be signaled of this event. In steps 1305 and 1306, when the VBevent is signaled, the driver code invokes a real time obfuscationcontrol thread. After the thread returns, thereby relinquishing controlto other tasks so that they too can paint the display, (or until the VBevent occurs) the driver just waits until the next signal or ioctl. Thereal time obfuscation control thread is described in reference to FIG.17.

Depending upon the particular implementation, an application (or theoperating system) may explicitly stop the obfuscation process (therebydestroying the secure region) or may simply change the data beingpresented in the already allocated secure region, or some combination ofboth. The “stop obfuscation” ioctl entry point is an interface forstopping the obfuscation process of a particular secure region. In step1307, if the ioctl received indicates a desire to “stop obfuscation”then in step 1308, the driver code signals the real time thread (if oneis currently running) to terminate (and obfuscate the secure portion).If a separate “DestroySecureDisplayRegion API (not shown) is used toinvoke the “stop obfuscation” ioctl, cleanup of the VDB and otherrelated data should be performed by that API.

Although the examples are described primarily with respect toimplementing driver code for one designated secure region, one skilledin the art will recognize that these techniques are extendible tomultiple requesters and multiple secure regions using standardprogramming techniques such as look up tables or by invoking one realtime obfuscation control thread (RTOC thread) per requester, or usingsimilar mechanisms. If multiple secure regions are being supported, thenthe driver code may register for a separate VB event for each secureregion and spawn a RTOC thread for each, otherwise it may send a list ofrelevant VB events to the RTOC.

FIG. 14 is an example flow diagram of interfaces in an example SecurityEnhanced Display Driver to control obfuscation of a secure displayregion in a non-event driven manner in an alternate operating systemenvironment. In summary, the driver code determines where the projectiongun needs to be in order to start obfuscation, spin-locks on the VBsignal+the calculated VB_event_start time to determine when to startde-obfuscation of the secure portion of the frame buffer, and spawns thereal time thread (same thread as for the approach used in FIG. 13) tode-obfuscate and re-obfuscate the secure portion. One skilled in the artwill recognize that a locking approach with finer granularity may beused. In particular, a non-real time thread may be spawned first toperform any processing of the data required for de-obfuscating prior tocopying the valid data into the FB. Thereafter, a real-time thread isspawned only to perform the copy-in of the valid data during there-obfuscation process. (In other words, the real-time thread is usedonly for processing from approximately point A to point B in FIG. 10.)

Specifically, in step 1401, the driver code determines whether thedriver has been invoked at the entry point corresponding to the “startobfuscation” process and, if so, continues in step 1403, else continuesin step 1404. In step 1402, the driver code allocates a secure portionof the frame buffer to correspond to the secure region on the display,if this is not already done by the corresponding API. In step 1403, thedriver code invokes a (non real-time) timing and synchronization threadto emulate the event handling to determine when the VB signalcorresponds to the VB_event_start. Then, either the timing andsynchronization thread invokes the real time obfuscation control threaddirectly, or it is done following step 1401 (approach not shown). Thedriver code then waits for the next signal or ioctl event. In step 1404,if the ioctl received indicates a desire to “stop obfuscation” then instep 1405, the driver code signals the real time thread (if one iscurrently running) to terminate (and obfuscate the secure portion).(Again, if a separate “API (not shown) is used to invoke the “stopobfuscation” ioctl, cleanup of the VDB and other related data should beperformed by that API.)

FIG. 15 is an example flow diagram of a vertical blank timing andsynchronization thread used to control the frame buffer contentscheduling in the alternate operating system environment of FIG. 14.This thread is called from step 1403 of FIG. 14. As stated, the primarypurpose of this thread is to simulate what would otherwise be availablefrom an operating system capable of signaling hardware events such as aspecific timing/location for the VB signal plus some delta of time (orcorresponding frame buffer location). In step 1501, the timing andsynchronization thread (TS thread) determines a VB_event_startlocation(time) in the frame buffer for starting the de-obfuscationprocess and a VB_event_end location(time) in the frame buffer forstarting the re-obfuscation process—that is, a VB (here simulated)“event” specification that corresponds to the beginning location of thesecure portion in the frame buffer adjusted for latencies,de-obfuscation, etc. (see Equation 1 above) and determines a VB “event”specification that corresponds to the end. A process for determining theVB_event_start and VB_event_end is described below with reference toFIG. 16. In step 1502, the TS thread spin-locks (polls and waits) on thedetermined VB_event_start, and when it hits it, then in step 1503invokes the real time obfuscation control thread (RTOC thread). Aspin-lock can be achieved by polling for the VB signal and setting atimer to go off at time VB+VB_event_start (or other equivalentmechanism). The real time obfuscation control thread is described inreference to FIG. 17. After the RTOC thread returns, therebyrelinquishing control to other tasks so that they too can paint thedisplay, the TS thread begins another spin-lock process in step 1502 topoll and wait for the timing of the next VB_event_start. If multiplesecure regions are being supported, then the TS thread may be simulatinga separate VB event for each secure region. At some point, the TS threadmay receive a signal to “terminate” (see representative step 1504) andwhen it does, then in step 1505, the TS thread signals the RTOC threadto terminate (and re-obfuscate any secure portions of the frame buffer).

FIG. 16 is an example flow diagram of code for determining correlationsbetween vertical blank and VRAM address as used to control frame buffercontent scheduling. As mentioned, the technique used is systemdependent, but the general idea is to determine at what point in timethe VB signal is occurring (at the rightmost bottom corner of thedisplay, how long it then takes to get to VB_event_start, the point atwhich de-obfuscation should start (see point A in FIG. 10), and how longit the takes to get to VB_event_end, the point at which re-obfuscationshould start. (The re-obfuscation point may begin sooner depending uponthe technique used as described earlier—pixel, scan line, or block at atime.) In step 1601, the code determines the time by whichde-obfuscation needs to have finished for a particular secure region(point A in FIG. 10). For example, this time can be computed knowing thescan rate (e.g., 80 mhz) and the number of scan lines to figure out therate per scan line and then figuring out the scan line position thatcorresponds to the start of the secure portion of the frame buffer. Instep 1602, if decryption (or de-masking) is used in the de-obfuscationtechnique in used, then the code continues in step 1603 to compute theVB_event_start taking into account extra time necessary for decryption(or de-masking). Otherwise, then in step 1604, VB_event_start iscomputed with system latencies, etc. As noted, these values need to bedetermined empirically, preferably during a system initializationprocess. In step 1605, the code determines VB_event_end by calculatingthe length of time needed to scan to the end of the secure portion andadding it to VB_event_start, or simple tracking it as a time difference.

FIG. 17 is an example flow diagram of a real-time obfuscation controlthread used by the Security Enhanced Display Driver to deliver valid andinvalid data to the frame buffer. The real-time obfuscation controlthread (RTOC thread) used by the display driver to lock out otherprocesses/tasks while the SEDD needs to display valid data. As noted,other equivalent process locking or resource (the frame buffer is aresource) locking mechanisms may be used, depending upon the operatingsystem and hardware environment. It is intended in this embodiment thatthe RTOC thread be the highest priority task in the system at thatpoint, so that all other processes/tasks are effectively locked out.Thus, the RTOC thread preferably acts very quickly and relinquishescontrol just as soon as the valid data is scanned and the secure portionre-obfuscated.

In step 1701, the RTOC thread determines whether decryption/de-maskingis needed, and, if so, continues in step 1702, else continues in step1703. In step 1702, depending of course on the obfuscation techniquebeing used by the SEDD, the RTOC thread creates valid data by decryptionor de-masking and sets an indicator to this value (pValidData). In step1703, since valid data is already available, the RTOC thread just usesthe valid data stored, for example, in the VDB. In step 1704, the RTOCthread copies in the indicated valid data to the secure portion of theframe buffer. In step 1705, the RTOC thread waits (if time not alreadypassed) until VB_event_end and then in step 1706 re-obfuscates thesecure portion of the frame buffer by whatever obfuscation technique isbeing used. (See, for example, FIGS. 8-9.) At some point (indeterminate)within the processing of the RTOC thread, the thread may receive asignal to terminate obfuscation. When it does, the RTOC preferablyexecutes step 1706 to make sure that the secure portion of the framebuffer contains obfuscated data.

Secure Storage and Display of Keyboard, Mouse and Other Pointing DeviceInput

FIG. 18 is an example block diagram that illustrates how input datahacking occurs. The diagram is meant to address all types of input, forexample, keyboard, mouse, and other pointing device input. In FIG. 18,as input is sent from the input device 1801 to an appropriate operatingsystem device driver 1802 it is processed by an appropriate input“stack” (code designed to handle and pass the input). As part of beingprocessed by the input stack, the input is forwarded to input routinesprovided, typically, by an application input library 1803, in order tosend the input to a requesting application. The input data, whiletransient, is vulnerable to sniffer applications 1804, which watch thedata to capture data and/or look for patterns in the input.

FIG. 19 is an example block diagram of the general techniques used by asecurity enhanced input driver, such as a Security Enhanced Mouse Driverto prevent unauthorized access to input data. The diagram shows the samecomponents as shown in FIG. 18, but with an additional component, theSecurity Enhanced Mouse Driver (the SEMD) 1905. The SEMD is a securedriver, which is invoked by applications or other code 1906 desiring toprovide secure input. The SEMD is preferably installed first-in-line sothat it hooks the input first from the hardware, before othercomponents, including the operating system drivers have a chance tointercept the input. A detailed description of how a driver is installedas a first-in-line driver and monitoring mechanisms for ensuring thatthe driver remains secure in its position are described below withreference to FIG. 23 and related text. In summary, the SEMD (or othersecure input driver) intercepts the data from the input device,determines whether it has been requested by an authorized applicationthat requested secure input (such as application 1906), and if so, sendsthe input in a secure fashion to the authorized application, otherwiseforwards the input on to the standard operating system drivers.

FIG. 20 is an example flow diagram of the obfuscation techniques used byan example security enhanced input driver to prevent unauthorized accessto input data. In FIG. 20, the input driver, for example, a mouse orkeyboard drvier, waits (typically at the request of an application orthe operating system as a result of a “read” request) until the nextinput event. In step 2001, when such an event is received, the drivercontinues in step 2002 to determine whether an “security authorized”requestor has issued the read request, and, if so, continues in step2004, else continues in step 2003. For the purposes described herein, asecurity authorize requestor is preferably an application or other codethat has specifically notified the secure input driver that secure inputis desired. Standard authentication mechanisms can be used toauthenticate the requestor after the requestor has initially registeredwith the secure input driver. In step 2003, the driver code determineswhether the authorized requestor has also specified that it desiresobfuscated input (to generate an added measure of security), and, if so,continues in step 2006, else continues in step 2005. In step 2005, theinput is then passed to the input “translation” stack offered by thesecure driver or libraries that handle the secure input in order toforward the input to the security authorized requestor. The inputtranslation stack typically determines, for example for keyboard input,a character, from a key code. In step 2006, when obfuscation has beenrequested, the input driver obfuscates the input code, using whateverobfuscation technique is implemented or specified. For example, theinput code can be encrypted, combined by Boolean operations with a mask,such as noise, a pattern, etc., much the same way display output can beobfuscated. In step 2007, the secure input driver code passes theobfuscated input code to an input translation stack that is coded tode-obfuscate the input code using the reverse technique to that whichwas used to obfuscate the input code.

Secure Storage and Display of Audio Content

FIG. 21 is an example block diagram that illustrates how audio datahacking occurs. As audio is sent from the operating system memory 2101or to memory on a sound card 2103 for playback on a speaker 2104, theaudio data is vulnerable while it is being stored on the sound cardmemory 2103 to malicious code, such as sniffer application 2106. Inaddition, for applications that handle streaming audio, the operatingsystem (or other application libraries) buffers audio temporarily inaudio buffers 2102. The buffered audio data 202 is also vulnerable tohacking such as by unauthorized sniffer applications 2205.

FIG. 22 is an example flow diagram of the obfuscation techniques used byan example Security Enhanced Audio Driver to prevent unauthorized accessto audio data. The diagram shows the same components as shown in FIG.21, but with an additional component, the Security Enhanced Audio Driver(the SEAD) 2207. The SEAD is a secure driver, which is invoked byauthorized applications or other code 2208 desiring to provide secureaudio output.

In one embodiment, the SEAD obfuscates the content of the pool of audiobuffers 2202 by selecting in a SEAD specific manner, which buffers touse for sequencing the audio. For example, a random or pseudo-randomsequence of numbers can be used to select which buffers to use toaccumulate the digital form of the audio signal. To confound attempts totrack utilization of the buffers, distracter information is placed intothe buffers that are not being used. As the audio is passed in digitalform to the next software component, if the component is authorized touse the SEAD for obscuring audio, then the audio is extracted from theaudio buffers 2202 using the same random or pseudo-random sequence ofnumbers to determine the appropriate source buffers. When the audio isno longer required, the buffer is returned to the pool of availablebuffers or optionally, has distracter information placed in it.

The SEAD also can be implemented to obfuscate the audio data sent to thecard by, for example, performing some operation “F” on the audio toencrypt or somehow encode or mask the data. (Operation “F” is soundcarddependent, and like other forms of encryption, has a counterpart reverseoperation for decryption purposes.) When the audio is presented by theSEAD to the soundcard for conversion to the analog audio signal, SEADinstructs additional software on the soundcard, for example a DSPpresent on certain soundcards, to perform the de-obfuscation. This maybe achieved on certain soundcards by creating an equalizer and soundprocessor code and treating the de-obfuscator codes in a manner similarto reverb, symphony hall, or other special effects.

In addition, when the SEAD is receiving a stream of audio information orthe receiving security authorized software is forwarding a stream ofaudio information to the SEAD, the digital representation of the digitalaudio information may be pre-obfuscated or encrypted, in a secure driverspecific manner, such that the SEAD can decrypt the audio in a safemanner. For example, the format of the may be encoded, or transcodedinto the form acceptable for use by that system. The origins of theaudio stream are derived from a conventional source, such as MP3 filesor streams, streaming servers, or other encoded digital audio sources.The receiving secure software, that knows how to decrypt these encodedaudio sources then renders the audio stream into the SEAD's internalobfuscation format such that plain “text” of the audio is never presentin the system in digital form.

First-in-Line SED Installation and Watchdog Monitoring

The ability to control when a driver has access to input and/or outputis especially important to security enhanced drivers. Each operatingsystem provides mechanisms for ensuring that a particular driver hasaccess before all other drivers, or before all of the drivers of itstype (for example, hard disk drivers), depending upon the operatingsystem. In operating systems similar to Windows 9x operating systems,event processing is performed in a “chain,” and drivers can be installedin various parts of the chain depending upon when they are loaded intothe system.

For example, input event processing for Windows 9x operating systemsproceeds typically as follows:

-   -   A hardware event occurs: mouse or keyboard activity (mouse        movement or key presses).    -   A VxD style (virtual) device driver (or system level driver)        detects and reads input from hardware and sends event to        hardware virtualization layer.    -   The virtualization layer successively sends the driver event        input to the list of device handlers registered for those        events; allowing each device handler function to process the        data or return without processing, allowing the next device        handler in the chain to process the data.    -   Driver events may be processed by the handler or sent on to the        application which registered for them.

Techniques of the present invention, when used in conjunction withWindows 9x operating systems, ensure that (especially) input SEDs areoptimally secure by installing the relevant drivers as the top (first)event handler in the handler chain for each input device. In addition, awatchdog process is invoked, as described further below to periodicallyvalidate the handler position. FIG. 23 is an example block diagram ofinstalling a SED as a first-in-line driver in Windows 9x operatingsystem environments and associated monitoring processes.

In Windows NT and derivative operating systems, input event processingfollows a different model. For example, input event processing in thesesystems proceeds typically as follows:

-   -   A Hardware Interrupt Service Routine (ISR) works fast to collect        data, building IRP I/O Request Packet    -   The ISR feeds into a Mini Port, which contains the hardware        interface and knowledge of the device.    -   Data is abstracted and passed up further to the Port Driver. The        port driver (usually 1 per I/O device). The port driver        abstracts the process further and does more processing on the        IRP    -   Data is then passed up to the Class Driver. Examples of this can        be mouse class and kbdclass. These are the standard mouse and        keyboard classes for the Windows Operating System.    -   Above the class drivers are the filter drivers, the filter        drivers can become the first to receive input and then determine        to pass it onto the existing system or not.    -   For example in Microsoft Windows OS a kernel driver can add        itself into the upper filter key of the registry to note that it        wants to receive key events.

Using the sequence as outlined above for NT OS I/O loading andprocessing, in one embodiment, a SED can be created as a class driver.The SED would then place a value in the upper filter of the registry todenote itself having input focus within the OS system. In thisembodiment, the SED needs to ensure that it is the first filter in theregistry along with ensuring that is the first of the filter drivers toreceive the I/O Request Packet directly from the class driver.

The concepts for implementing a watchdog service to monitor security inboth the Windows 9x and NT are similar, however the implementationvaries to adhere to the driver model of each operating system. Byinserting a SED's filtering (and potentially obfuscating) function asthe first function to examine and/or process the driver's event data,SEDs ensure the validity and security of the mouse, keyboard, and otherinput devices; either processing the data for the secure environment orallowing the data to be returned to the operating system via the normalmechanism. One skilled in the art will recognize that similar techniquescan be developed in other operating system environments, as long as thedriver model is known and an SED filtering function can be appropriatelyinserted.

One skilled in the art will also recognize that no distinction is madebetween the mouse and keyboard devices for the purposes of using thesetechniques. The device drivers both operate in a similar manner for thepurposes of this description. In addition, these techniques may beimplemented with a trackball, a digitized tablet, a cordless keyboard, acordless mouse, a numeric keypad, a touch pad, or any other pointer orkey-based input device.

In an example Windows 9x implementation, a SED security service isinstalled which acts as a timer. Upon startup, the SED security serviceestablishes a communications path to the SED driver using a standardmechanism, IOCTLO. Via the IOCTL path, the SED security service signalsthe SED to verify that the SED is in the first (top) device handlerposition in the event processing handler chain of the mouse andkeyboard. If this is not the case, the SED attempts to re-register theSED handler into the first position. If this attempt fails an errormessage is registered and the system is now considered to be unsecurefor obfuscation purposes.

Upon detection of an unsecure environment, an event, for example, aapplication-specific event, is propagated through the environment, toinform all relevant applications. For example, in the xSidesenvironment, described in detail in U.S. patent application Ser. No.09/726,202, entitiled “Method and System for Controlling a ComplementaryUser Interface on a Display Surface,” filed on Nov. 28, 2000, an xSidesevent is prograted throughout, informing all xSides applications thatrely on secure input functionality that those devices (e.g., mouse andkeyboard devices) are no longer considered secure. This change ofsecurity is communicated preferably to the user as well via an iconwhich is displayed in a secure region (as described above in the sectionentitled “Secure Storage and Display of Video Content.” Common bimapsused for this purpose are a locked or unlocked padlock.

To ensure that continuous security validation checks occur by thesecurity service, a second service is started up to act as a watchdog tothe SED security service called the SED security watchdog. The purposeof the security watchdog is to establish a bi-directional communicationspath to the security service on which messages are sent to and from thetwo services. These messages act as an “I'm alive” or ping mechanism,which informs each service that the other is functioning normally. Ifone service fails to receive a message from the other in some arbitrarytime period, an attempt by the receiving service will be made to restartthe other service.

If the receiving service is unable to restart the other service, thenthe system, for obfuscation purposes, is considered unsecure and thesame notification to the user is performed as described above for thesecurity service.

The security service for Windows NT derivative operating systems isessentially the same as for the Windows 9x version. One difference isthat the value being verified is not a handler chain, but instead thevalue of the callback function pointer in the I/O completion structuresfor the input devices (e.g., mouse and keyboard). This is done by acomparison of the function pointers. If the SED callback function is notthe callback function pointed to in the I/O completion structure, anattempt to replace it will be made. The failure modes described forWindows 9x for failing to change the function pointer for the callbackfunction to the SED version are also preferably available for theWindows NT technique; i.e., secure/un-secure notification.

The basic SED security watchdog service operates similarly in theWindows NT environment as in the Window 9x environment.

An additional watchdog service (or an extension of the existing service)may be made available to verify the status of hooks, and verify that theSEDs have not been tampered with. An NT implementation includes twoseparate processes that registers an interest in two different systemregistry entries. If they are not in sync, the watchdog service notifiesor automatically repairs registry entries that are not correct. The tworegistry entries have sufficient state to allow the watchdog executableto verify that the registry entries have not been tampered with. Thismay be, for example, the storing of the checksum, certificates, or thesignature of the application in the registry entries of the watchdogitself, along with an XOR of the signature and another known value, oralternatively a signature derived by a different mechanism than thefirst. The watchdog is invoked if the registry entries are modified andverifies that the entries are correct at that time; and, if they are notcorrect, determines the correct values and replaces them. Since it isunlikely that (1) the signatures stored in the registry, (2) thewatchdog itself, (3) the software the signatures were derived from, and(4) the software that verifies the watchdog itself can all be changed ina manner as to appear valid, this mechanism alone or in combination withother measures may be used to determine the state of intrusion ormodification of the software codes.

Denoting Security in User Interfaces

As mentioned, to complement the obfuscation techniques and securityenhanced drivers, the methods and systems of the present invention alsoprovide different techniques for denoting various levels of security inthe system. Some existing systems, such as applications like a webbrowser, provide a basic graphical representation of security orsecurity-level. Microsoft's Internet Explorer for example, uses arepresentation of a “padlock” located in the bottom status bar region ofthe browser to represent to the user that a web site location iscurrently using secure or non-secure communication protocols, usually inthe form of technologies such as SSL or HTTPS. FIG. 24 is an examplescreen display that illustrates a padlock to denote security as used inan existing software application.

The security enhanced drivers of the present invention provide amechanism by which a secure region on the display device, such as adisplayed desktop, window, or an alternative display area may use thedisplay cursor to intuitively identify to the user the security level ofthe region. Specifically, each secure region is associated with anattribute value that causes the display cursor to inherit a color valuefor the level of security associated with the specific region. As thecursor is moved, whether automatically or by the user, from one displayarea into another display area with a higher or lower security level,the cursor color and/or representation can change to an appropriatevalue. For example, as a user moves the cursor from within a non-secureWindows desktop display area into the alternative display area createdby a alternative-display technology such as that developed by xSidesCorporation, the cursor color may change from white to red or it maychange from the standard Windows arrow cursor into a gold-keyrepresentation.

Similarly, this denotation mechanism can be used in an environment wheremultiple secure (or unsecure) regions are displayed on a display device,each with different inherent capabilities or security values. Thesecurity values associated with each region are queried using amechanism such as the standard Microsoft Windows API routine, SetCursor(). The return value of the SetCursor( ) routine contains the informationnecessary for application to identify the security level associated withthe specific region.

This denotation mechanism is not limited to using a cursor as a means ofsecurity representation. One skilled in the art will recognize thatother components of the desktop display or regions within or outside thedesktop display can reflect the security level and capabilities to theuser. If a secure desktop is loaded it can contain attributes that allowthe end-user to distinguish its security level through a visible orauditory alteration to the windows of the secure desktop. For example, asecure desktop may have a lock or key associated with it and blendedinto a corner of the desktop display. The desktop might also take adifferent gradient of color when associated with a different securitylevel. A window, an alternative display, or an arbitrary secure regionmay contain a colored border, which is associated with the securitylevel. Or, for example, the surrounding border may change width,pattern, or even look like a chain, depending the security level of thewindow, alternative display, or secure region. Other implementationsregarding the alteration or additions to the window, display, or regionmay optionally be used, such as placing additional decoration above thearea, a diagonal striped black and yellow bar for example, or otherplacement in immediate proximity to the area, or within the area itself.Another alternative is to change the appearance of a standard userinterface element decoration, such as a scroll bar, to an alternativeform, pattern, color, or any combination of these. In addition, or incombination with the above variations, changes to the Title Bar,caption, or navigation icon may also be used to denote the level ofsecurity provided by the associated software of a particular window orregion. These changes may be as simple as rendering the title barcaption in a different color set, or denoting a number or other symbolover the navigation icon of the window. FIG. 25 is an example screendisplay that illustrates use of the cursor to determine a security leveland other representations on windows used to denote security. Oneskilled in the art will recognize that other similar techniques may beincorporated.

In the event that security can be provided or assured through multiple“agencies” or instances of software, it may benefit the user to know theorigin of the security assurance. The system preferably indicates thesecurity level through any of the mechanisms described above, whileproviding either persistent text denoting the security provider in thetitle bar, above the title bar, in a status bar, or other relativelyfixed location, or in a non-persistent manner, such as a pop-up display,“tool tip” display, or transient text display in some other portion ofthe window or secure region of the display device. This transient textdisplay may be triggered periodically, or by some outside event such asentry into the security state or movement of the text or mouse cursorover the security icon.

All of the above U.S. patents, U.S. patent application publications,U.S. patent applications, foreign patents, foreign patent applicationsand non-patent publications referred to in this specification and/orlisted in the Application Data Sheet, including but not limited to, U.S.Provisional Patent Application No. 60/297,273 entitled “Method andSystem for Maintaining Secure Data Input and Output,” filed Jun. 8,2001, U.S. patent application Ser. No. 09/726,202 entitled “Method andSystem for Controlling a Complementary User Interface on a DisplaySurface,” filed Nov. 28, 2000, and U.S. Pat. No. 6,018,332, entitled“Overscan User Interface,” issued on Jan. 25, 2000, and U.S. Pat. No.6,330,010, entitled “Secondary User Interface,” issued on Dec. 11, 2001,are incorporated herein by reference, in their entirety.

From the foregoing it will be appreciated that, although specificembodiments of the invention have been described herein for purposes ofillustration, various modifications may be made without deviating fromthe spirit and scope of the invention. For example, one skilled in theart will recognize that the methods and systems for secure data inputand output are applicable to other types of storage and input devicesand to other types of data, streamed or otherwise, other than thoseexplicitly described herein. For example, the obfuscation techniquesused to obfuscate data within the frame buffer may be extended toobfuscate other types of storage. In addition such embodiments may beextended to provide a content scheduler for such storage usingtechniques similar to those described with respect to the securityenhanced drivers described herein.

1. A method in a computer system for providing a secure display area ona video display device of a video display system, the video displaysystem having video display memory for storing data to be displayed onthe video display device, comprising: reserving a portion of the videodisplay memory for secure data storage that corresponds to the securedisplay area; receiving a request to display valid data in the securedisplay area, the request including an indication of the valid data;storing the indicated valid data in a secure data buffer; and storinginvalid data in the reserved portion of the video display memory until adetermined period of time before the data stored in the reserved portionis transferred to the video display device for display.
 2. The method ofclaim 1, further comprising: at the beginning of the determined periodof time, replacing the invalid data stored in the reserved portion ofthe video display memory with valid data from the secure data buffer. 3.The method of claim 2, further comprising: after the data stored in thereserved portion is transferred to the video display, re-storing theinvalid data in the reserved portion of the video display memory.
 4. Themethod of claim 1 wherein the secure data buffer is implemented bystoring the valid data in the reserved portion of the video displaymemory as encrypted data.
 5. The method of claim 1, the video displaymemory having a frame buffer that stores data that is to be displayed onthe video display device, wherein the secure data buffer is a portion ofthe frame buffer.
 6. The method of claim 5 wherein the valid data isobfuscated prior to storing in the secure data buffer.
 7. The method ofclaim 1 wherein the valid data is obfuscated prior to storing in thesecure data buffer.
 8. The method of claim 7 wherein obfuscation isperformed by at least one of encryption of the valid data and a rasteroperation applied to the valid data and a mask.
 9. The method of claim 8wherein the mask is a bitmap comprising at least one of an encryptionkey, a company logo, a pattern, an advertisement, and a black region.10. The method of claim 1 wherein the secure data buffer is one of anarea in the video display memory, a portion of random access memory inthe computer system, a secondary memory that resides on a video cardthat controls the video display device and storage accessible by othermeans.
 11. The method of claim 10 wherein the secure data buffer islocated in the reserved portion of video memory while the valid data isbeing displayed.
 12. The method of claim 10 wherein the location of thesecure data buffer is one of a user designated, application designated,and system designated location.
 13. A secure video display driver forproviding a secure display area on a video display device of a videodisplay system, the video display system having video display memory forstoring data to be displayed on the video display device, comprising: adata receiver that is structured to receive a request to display validdata in the secure display area, the request including an indication ofthe valid data; and a video display memory scheduler that is structuredto: reserve a portion of the video display memory for secure datastorage that corresponds to the secure display area; store the indicatedvalid data in a secure data buffer; and store invalid data in thereserved portion of the video display memory until a determined periodof time before the data stored in the reserved portion is transferred tothe video display device for display.
 14. The display driver of claim 13wherein the video display memory scheduler is further structured to: atthe beginning of the determined period of time, replace the invalid datastored in the reserved portion of the video display memory with validdata from the secure data buffer.
 15. The display driver of claim 14,wherein the video display memory scheduler is further structured to:after the data stored in the reserved portion is transferred to thevideo display, store invalid data in the reserved portion of the videodisplay memory.
 16. The display driver of claim 13 wherein the securedata buffer is implemented by storing the valid data in the reservedportion of the video display memory as encrypted data.
 17. The displaydriver of claim 13 wherein the secure data buffer is one of an area inthe video display memory, a portion of random access memory in thecomputer system, a secondary memory that resides on a video card thatcontrols the video display device and storage accessible by other means.18. The display driver of claim 13 wherein the secure data bufferlocation is one of a user designated, application designated, and systemdesignated location.
 19. The display driver of claim 13, the videodisplay memory having a frame buffer that stores data that is to bedisplayed on the video display device, wherein the secure data buffer isa portion of the frame buffer.
 20. The display driver of claim 13wherein the valid data is obfuscated prior to storing in the secure databuffer.
 21. A computer-readable memory medium containing instructionsfor controlling a computer processor to provide a secure display area ona video display device of a video display system, the video displaysystem having video display memory for storing data to be displayed onthe video display device, by: reserving a portion of the video displaymemory for secure data storage that corresponds to the secure displayarea; receiving a request to display valid data in the secure displayarea, the request including an indication of the valid data; storing theindicated valid data in a secure data buffer; and storing invalid datain the reserved portion of the video display memory until a determinedperiod of time before the data stored in the reserved portion istransferred to the video display device for display.
 22. A method in acomputer system for ensuring the secure receipt of input from an inputdata device, the computer system having a system input device drivercode and an ordering of device driver codes such that a first devicedriver code gains control before other device driver codes, comprising:installing a modified input driver code as the first device driver code,thereby insuring that the system input device driver code does notprocess an input event first; and under control of the modified inputdriver code, receiving an input event; determining whether the inputevent is designated as a secure input event; and when it is determinedthat the input event is a secure input event, processing the inputevent.
 23. The method of claim 22, further comprising: forwarding theinput event to the system input event device driver code when it isdetermined that the input event is not a secure input event.
 24. Themethod of claim 22 wherein the input device driver code controls apointing device.
 25. The method of claim 22 wherein the input devicedriver code controls a keyboard device.
 26. The method of claim 22wherein the input device driver code is responsive to an audio device.27. The method of claim 22 wherein processing the input event comprisespassing the input event to a recipient authorized to receive the secureinput event.